(1) Field of the Invention
The present invention pertains to the field of software development for embedded systems. More particularly, the present invention pertains to the field of integrated software development environments for embedded systems in which the software specific to the development tasks is resident on the target microcontroller (MCU), with the target microcontroller being adapted to connect to a remote user terminal by means of a development-environment independent transport mechanism.
(2) Description of Related Art
FIG. 1 is a schematic representation of a first traditional approach to embedded system development. In this approach, a host computer 10 provides very low-level control of a CPU core 21 of a system-on-a-chip type microcontroller μC embedded in a target board 20 by controlling an external in-circuit emulator 30, which in turn controls the target board CPU core 21 using a low-level hardware mechanism (such as JTAG or BDM). The host computer also typically controls an external flash programmer 40 to download the target board control program to the target board's flash memory 22, also using a low-level hardware mechanism (such as JTAG or BDM).
As shown in FIG. 1, the editor, compiler, flasher, and debugger used for software development run on the host computer 10. The flasher and debugger interact with the flash programmer 40 and the in-circuit emulator 30 to control the CPU core 21 and the flash memory 22 on the target board 20.
In the software development process of FIG. 1, the host computer 10 is used to:
1. edit and store the target board control program source code,
2. compile the target board control program source code to a binary code suitable for the target board's CPU core, and generate symbolics information for debugging,
3. download the target board control program binary code to the target board's flash memory through the flash programmer, and
4. control the execution and debug of the target board control program, through the in-circuit emulator, until it is working correctly.
Once the target board control program is working correctly, the host computer 10 (and the in-circuit emulator 30 and flash programmer 40) can be disconnected from the target board 20, and the target board 20 can be run in stand-alone mode. Thereafter, typically, other target boards can be “just flashed” (step 3, above) by hooking them up to a much more limited form of a host computer (without the ability to edit, compile, or debug the target board control program) with a flash programmer.
FIG. 2 is a schematic representation of a second traditional approach to embedded system development. In this approach, the need for an in-circuit emulator (and potentially the need for a flash programmer) is removed by adding a small amount of protected low-level software to be executed by the target board's CPU core 21. This protected low-level software, known as a “debug monitor”, communicates CPU state information to the host computer 10 over a development-environment dependent transport mechanism 50. The editor, compiler, flasher, and debugger software still run on the host computer 10, with the debug monitor essentially being a slave to the main flasher and debugger program running on the host computer 10.
An example of a target resident debugging kernel for embedded systems is shown at http://www.freescale.com/files/soft_dev_tools/doc/white_paper/CWMETROTWP.pdf (Grehan, Rick, MetroTRK: Target Resident Debugging Kernel for Embedded Systems).
U.S. Patent Application Publication 2005/0055665 to Woo et al. reveals a system and method for developing a target application on a target system in a cross development environment. A source editing unit is provided in the target system, but the cross compiling unit still resides on the host.
Other attempts have been made to incorporate embedded system development software/functionality into the target system.
A debugger which is disposed completely inside a real-time operating system and runs on the target processor (with the host running the user interface only) is described in Akgul, T. et al., “A Debugger RTOS for Embedded Systems”, Euromicro Conference 2001 Proceedings, pages 264-269. A similar debugger is shown in U.S. Patent Application Publication 2003/0074650 to Akgul et al.
Compact operating systems such as Inferno (http://www.vitanuova.com/inferno/index.html; http://www.vitanuova.com/solutions/embedded/index.html; http://www.vitanuova.com/inferno/papers/dev.html; and http://www.vitanuova.com/mkt/press/Inferno_overview.pdf) can apparently be run on embedded devices having as little as 1 MB of RAM. In one configuration, Inferno includes an integrated development environment (IDE), compiler, shell, and graphical debugger.
A development platform which can be used to develop and run programs on a Renesas M30626FHPFP processor independently of a host PC is described in a published contest entry entitled “ReVaLuaTe” by Bogdan Marinescu submitted for the Renesas M16C Design Contest 2005 (see http://www.circuitcellar.com/renesas2005m16c/winners/1685.htm and the linked “Abstract” page and the “Entry” link which points to the source-code containing file M1685.zip). The ReVaLuaTe platform includes a Lua bytecode compiler, a built-in editor, and a flasher. The entry further suggested that an interactive debugger might be added as an important feature and was seen by the author to be “not as difficult as it sounds” (see Section 8, Conclusions and Future Work). However, during program development, the ReVaLuaTe system apparently requires the storage of both a source file and Lua compiled file (which is compiled from the source file with the “comp” command); this may result in increased memory requirements for the system during program development. Moreover, the ReVaLuaTe architecture utilized a 512 kB off-chip SRAM in addition to the processor RAM and flash. For system-on-a-chip (SoC) type embedded microcontroller applications, it is highly desirable that the development environment software reside completely in and run completely from the on-chip memory of the microcontroller chip itself, without the need for external (i.e., off the microcontroller chip) memory. It is also desirable that the interactive debugger have the ability to modify data (e.g., the values of program variables) and alter code execution during debug.
Recently, the Jumentum-SOC (formerly called MiniOn) programming environment for LPC2000-based microcontroller chips has been developed and published by Daniel Marks (http://jumentum.sourceforge.net/; formerly http://minion-system.sourceforge.net/; see also the source-code containing file Jumentum-src-0.92.2.zip linked to from the page http://sourceforge.net/project/showfiles.php?group_id=224582). The Jumentum-SOC programming environment is intended to lower both the cost and complexity of microcontroller embedding and uses a Basic-derived language. It is remotely programmable through the use of a web browser, a TELNET text-based session, or a serial port. The Basic programming environment is self-contained on the microcontroller chip and uses a built-in text editor and a Basic interpreter for program creation and execution. Jumentum-SOC programs (e.g., user programs) can be downloaded into the microcontroller and programmed into the microcontroller's flash memory so that the programs are automatically run when the microcontroller is powered up. The programs can be started, stopped, paused, and the program variables inspected at any time through the web browser page. However, for system-on-a-chip (SoC) type embedded microcontroller applications, it is desirable to use a bytecode or native compiler rather than an interpreter for performance reasons. It is also desirable to incorporate an interactive debugger, with the ability to modify data (e.g., the values of program variables) and alter code execution during debug.
Finally, when considering the ReVaLuaTe and Jumentum-SOC systems, it is desirable that such a microcontroller-resident software development environment support application-level interrupt handlers and the use pin variables which can be bound to the external I/O pins of the microcontroller chip. This is particularly true for embedded systems where a fast “external event response time” can be critical to the application.